The progress and success of a software design project rely on tools for analysis of the flow of program execution. A quick detection of defects in the software design is essential for achieving short development times.
Modern software design projects are often targeted at embedded processors, for instance in a System-on-Chip (SoC), and often times at multicore processor architectures. Wellknown embedded trace architectures for SoCs are known as the CoreSight architecture by ARM, Limited, as described in the references CoreSight™ Components-Technical Reference Manual-DDI 0314H, ARM, 2009, and CoreSight Technology System Design Guide, ARM Limited, 2010, and Embedded Trace Macrocell Architecture Specification, ARM Limited, 2011 and the Nexus standard, which is for instance used in Power Architecture® based microcontrollers designed by Freescale Semiconductor Inc. and described in detail in IEEE-ISTO, “The Nexus 5001 Forum—Standard for a Global Embedded Processor Debug Interface,” IEEE-ISTO 5001TM-2012, June 2012 (December 2003).
In such systems, there is a need to comprehensively monitor the program execution flow, for instance in order to be able to detect non-deterministic errors, which may occur in such systems with high probability, and to remove the defects causing such errors.
For monitoring the program execution flow of embedded processors, embedded trace devices are used, which collect internal state information on the chip, filter it and provide a strongly compressed output containing the filtered state information. The ascertaining of trace data uses two different strategies. Trace data may be stored in the SoC and read later via a suitable interface (on-chip trace memory). As an alternative or in addition, trace data may be buffered and output shortly after they have been ascertained and then be stored outside the SoC for further processing (off-chip trace memory). Due to the limited memory capacity of SoCs, on-chip solutions are used only for very simple analyses. More comprehensive analyses require off-chip solutions.
In order to follow a program execution flow in a processor, the executed instructions, data accesses and other information have to be provided for analysis. This is done in the form of trace data forming a trace data stream.
The trace data stream is processed by a development system, which is configured to restore the program execution executed by the device under test or observation (DUT).
The bandwidth requirements for the interface providing the trace data stream from the DUT to the developer's system depend on the information to be gained from the trace data. An increasing information need has led to the use of compression techniques for trace data.
According to the current art, trace data are stored in a memory of an emulator or of a computer of a developer's system, and then analyzed offline. The program execution flow can thus be monitored over only a limited time span defined by the available storage capacity of the memory. Furthermore, the transfer of the trace data and the offline computation time accounts for an indistinct delay between the events occurring in the DUT during the program execution flow and the availability of the corresponding trace data for analysis.